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1 This action is in response to the communication filed on 1 1/30/2007. 

2 DETAILED ACTION 

3 Claims 1-10, 13-25, 28-38, 40-47, and 49-57 have been examined. 

4 Response to Arguments 

5 Applicant's arguments filed 1 1/30/2007 have been fully considered but they are not 

6 persuasive. 

7 Applicant's arguments do not comply with 37 CFR 1 . 1 1 1(c) because they do not clearly 

8 point out the patentable novelty which he or she thinks the claims present in view of the state of 

9 the art disclosed by the references cited or the objections made. Further, they do not show how 

10 the amendments avoid such references or objections. 

1 1 Regarding applicants' assertion that "only disclosing that multiple protocols exist at 

12 different layers in the TCP/IP protocol suite. . .fails to specifically teach 'reassembling one or 

13 more of the incoming datagrams into a segment structured in compliance with a transport 

14 protocol layer'", the examiner does not find the argument persuasive. First, the examiner 

15 admitted that Trcka did not specifically disclose this limitation. Second, the examiner has 
16 . explained, and relied upon, the fact that segmentation and reassembly of datagrams is well 

17 known in TCP/IP, which is, and was at the time of invention, a very well known and used 

1 8 standard. Furthermore, the fact that Trcka disclosed performing scanning on upper layer files 

19 which rely upon TCP/IP for transmission, renders obvious the use of the TCP/IP stack of 

20 protocols as well as the OSI protocol model. As evidenced by Stevens on Page 148 Section 11.5, 

21 as well as Pages 6-11, TCP/IP performs "reassembling one or more of the incoming datagrams 

22 into a segment structured in compliance with a transport protocol layer" when receiving packet 
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1 data and converting the packet data to upper protocol (application layer). As such, this limitation 

2 is rendered obvious in the system of Trcka. As such, the examiner does not find the argument 

3 persuasive. 

4 Regarding applicants' assertion that "Clearly, only generally disclosing a module that 

5 processes packets based on protocol specific packet fields, as in Trcka, fails to meet applicant's 

6 claimed 'protocol-specific module processing each reassembled datagram based on the transport 

7 protocol layer employed by the reassembled datagram" 1 , the examiner does not find the 

8 argument persuasive. First, the examiner has already admitted that Trcka did not specifically 

9 disclose this limitation. However, Trcka did disclose in col. 14 Lines 49- 65, that the Post- 
10 Capture Processing Module automatically reads in and analyzes the data from the recorders 

1 1 which store continuous packet data. Trcka further disclosed that the data was analyzed based 

12 upon the specific file types, which is application layer data. As evidenced by Stevens, and well 

13 known in the art, the TCP/IP protocol stack performs processing of datagrams based on the 

14 transport protocol layer employed by the reassembled datagram in order to produce application 

15 layer data from packet data. As such, this limitation has been rendered obvious, and the 

16 examiner does not find the argument persuasive. 

1 7 Regarding applicants' assertion that Trcka does not teach " receiving copies of datagrams 

1 8 transiting a boundary of a network domain " the examiner does not find the argument persuasive. 

19 Col. 19 Paragraph 2 and Fig. 8 disclose a Firewall, which is a network boundary, wherein the 

20 data packets are captured from both sides of the firewall. Furthermore, Trcka teaches that the 

21 packet data is a passively captured replica of the network traffic, and a replica is a copy. Further 

22 still, Trcka states that the passively generated data stream "represents the traffic present on the 
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1 network" (See Trcka Col. 10 Lines 59-63, which further implies that the passively generated data 

2 stream is not the traffic present on the network, but rather it is a copy of the traffic present on the 

3 network. Even further still, "the traffic present on the network" falls within the scope of a 

4 "packet stream". As such, the examiner does not find the argument persuasive. 

5 Regarding applicants' argument that Trcka did not teach reassembling datagrams from 

6 the incoming packet queue, the examiner does not find the argument persuasive. Trcka teaches 

7 that the cyclic data recorder temporarily stores the passively captured traffic data (packet 

8 stream), which meets the limitation of "the incoming packet queue". Trcka further teaches the 

9 data is read out of the cyclic data recorder to checked for viruses, as can be seen in Col. 4 

10 Paragraph 1. Trcka further disclosed that the scanning is performed on files such as HTTP files, 

1 1 FTP files, etc. (See Col. 14 Lines 61-64). As evidenced by the teachings of Stevens, converting 

12 the packets to HTTP files or FTP files involves demultiplexing from the network layer, which 

13 includes IP, to the transport layer, which includes TCP, to the application layer, which includes 

14 HTTP and FTP. Stevens further evidences that the demultiplexing from IP to TCP involves 

15 reassembly of datagram fragments, as seen on Page 148 of Stevens. It is therefore obvious that 

16 the after defragmenting at the IP layer, and prior to demultiplexing from the defragmented IP 

17 datagram to the TCP Segment, the defragmented IP datagram would have to be stored 

18 somewhere, or it would be lost. This storage is a queue, and meets the limitations of the claim 

19 language. As such the examiner does not find the argument persuasive. 

20 Regarding applicants' argument that Trcka does not disclose "scanning each network 

21 protocol packet from the reassembled packet queue", the examiner does not find the argument 

22 persuasive. Again, this limitation has been shown as obvious in view of Trcka as evidenced by 
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1 Stevens. In this combination, because the reassembly occurs prior to the packets becoming files, 

2 as is evidenced by Stevens, and because the files, which are demultiplexed from the packets, are 

3 what is being scanned, it is obvious that each reassembled packet is scanned. Further, as 

4 discussed above, each reassembled packet is obviously stored in u a queue". Therefore the 

5 examiner does not find the argument persuasive. 

6 Regarding applicants' argument that Trcka did not disclose that a "protocol-specific 

7 module that processes each reassembled datagram based un an upper protocol layer employed by 

8 the reassembled datagram", the examiner does not find the argument persuasive. This is simply 

9 another obvious feature of TCP/IP, as evidenced by Stevens. In this case, Trcka disclosed 

10 creating the application layer files for scanning, such as HTTP files, and FTP files, and as 

1 1 discussed above, TCP/IP reassembles fragmented datagrams at the IP layer, then sends the IP 

12 datagram to the transport layer protocol corresponding to that datagram, which demultiplexes the 

13 datagram based upon the protocol for that packet, such as TCP or UDP. This falls within the 

14 scope of the claim language, and as such the examiner does not find the argument persuasive. 

15 Regarding applicants' argument that Cheriton did not disclose or render obvious 

16 "wherein the antivirus scanner terminates the transient packet stream if the reassembled segment 

17 is not infected with at least one of a computer virus or malware", the examiner does not find the 

18 argument persuasive. First, the examiner points out that Denial of Service attack packets are not 

19 infected with viruses or malware, but rather are either contain invalid parameters or are 

20 transmitted in large quantities. Second, the examiner points out that only one of the possibilities 

21 has been addressed by the claim language, and says nothing about the situation when the packet 

22 is infected. As such, the teachings of Cheriton do render obvious the scenario when the packets 
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1 are not infected and the stream is stopped. Therefore the examiner does not find the argument 

2 persuasive. 

3 Regarding the applicants' argument regarding claim 55, reassembly from IP to TCP has 

4 been addressed above, and thus is not addressed further. However, the examiner notes that the 

5 applicants have misconstrued Trcka by stating that the security checks are performed on packet 

6 data. Trcka clearly disclosed performing security checks on files, which are created from packet 

7 data. See Trcka Col. 14 Lines 49-64. 

8 All objections and rejections not presented below have been withdrawn. 

9 Claims 1-10, 13-25, 28-38, 40-47, and 49-57 have been examined. 

10 Specification 

1 1 The specification is objected to as failing to provide proper antecedent basis for the 

12 claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the 

13 following is required: In this case, the specification lacks antecedent basis for the newly recited 

14 claim 56. See the rejection of claim 56 under 35 USC 1 12 1 st Paragraph below. 
15 

1 6 Claim Rejections - 35 USC §112 

17 The following is a quotation of the first paragraph of 35 U.S. C. 1 12: 

1 8 The specification shall contain a written description of the invention, and of the manner and process of making 

1 9 and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 

20 pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
. 2 1 contemplated by the inventor of carrying out his invention. 

22 

23 Claim 56 is rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with the 

24 written description requirement. The claim(s) contains subject matter which was not described 

25 in the specification in such a way as to reasonably convey to one skilled in the relevant art that 



Application/Control Number: 1 0/06 1,415 Page 7 

Art Unit: 2131 

1 the inventor(s), at the time the application was filed, had possession of the claimed invention. In 

2 this case, although the examiner has found support for the antivirus scanner spoofing a packet, 

3 by sending a legitimate packet in place of the infected packet, the examiner can find no support 

4 for "the spoofed network packet" sending a legitimate packet, as claimed. Furthermore, the 



5 applicants have failed to show where support for this limitation can be found in the specification. 

6 As such, one of ordinary skill in the art would not be able to ascertain whether the applicants 

7 were in possession of the invention as claimed at the time of application. Therefore, claim 56 is 

8 rejected for failing to meet the written description requirement of 35 USC 112 1st Paragraph. 

9 The following is a quotation of the second paragraph of 35 U.S. C. 1 12: 

1 0 The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 

1 1 subject matter which the applicant regards as his invention. 
12 

13 Claim 56 is rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 

14 failing to particularly point out and distinctly claim the subject matter which applicant regards as 

15 the invention. 

16 Claim 56 recites "the system of claim 47", while claim 47 is directed to a method and not 

17 a system. 

1 8 Claim 56 recites the limitation "the spoofed network packet". There is insufficient 

19 antecedent basis for this limitation in the claim. This can be remedied by changing the limitation 

20 of "a spoofed network protocol packet" to "a spoofed network packet" in claim 47. 

21 Claim 56 is rejected under 35 U.S.C. 1 12, second paragraph, as being incomplete for 

22 omitting essential elements, such omission amounting to a gap between the elements. See MPEP 

23 § 2172.01. The omitted elements are: the destination of the legitimate packet, or that the method 
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1 sends packets at all, let alone the infected packets for which the spoofed packets are to be sent in 

2 place. 

3 Appropriate correction is required. 

4 Claim Rejections - 35 USC §103 

5 The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

6 obviousness rejections set forth in this Office action: 

7 (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 

8 section 102 of thus title, if the differences between the subject matter sought to be patented and the prior art are 

9 such that the subject matter as a whole would have been obvious at the time the invention was made to a person 

1 0 having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 

1 1 manner in which the invention was made. 

12 

13 Claims 1-3, 5-10, 13-14, 16-18, 20-25, 28-29, 31, and 55, are rejected under 35 U.S.C. 

14 103(a) as being unpatentable over Trcka et al. (US Patent Number 6,453,345) hereinafter 

15 referred to as Trcka, and further in view of Stevens (TCP/IP Illustrated). 

16 Regarding claims 1,16, and 31, Trcka disclosed a system for providing passive 



17 screening of transient messages in a distributed computing environment (See Trcka Abstract), 

18 comprising: a network interface (See Trcka Fig. 1 Element 38) passively monitoring a transient 

19 packet stream in a network boundary (See Trcka Col. 2 Lines 1 1-22) comprising receiving 

20 incoming datagrams structured in compliance with a network protocol layer (See Trcka Col. 2 



21 Lines 23-24); an antivirus scanner scanning contents of the packets for a presence of at least one 

22 of a computer virus and malware to identify infected message contents (See Trcka Col. 3 Line 66 

23 - Col. 4 Line 16); and a protocol specific module processing each packet based on the protocols 

24 employed by the packet (See Trcka Col. 13 Lines 32-49), but Trcka failed to specifically disclose 

25 a packet receiver reassembling one or more of the incoming datagrams into a segment structured 

26 in compliance with a transport protocol layer; or that the protocol specific module processed the 
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1 reassembled datagrams based on the transport protocol layer employed by the reassembled 

2 datagram. However, Trcka did disclose performing virus scanning on specific upper layer files 

3 such as FTP, HTTP, SMTP, and others (See Trcka Col. 14 Lines 62-67). 



5 layer contains different modules, such as the TCP module and the UDP module of the transport 

6 layer. It was also well known that in order to get to the data in the application layer packet, such 

7 as the payload and the packet type, the transport layer module must process the transport layer 

8 packet to reveal the application layer packet. This is evidenced by Stevens Pages 6-11. 



10 invention to employ what was well known in the art of networking and TCP/IP in order to gain 

1 1 access to the data in the packets for scanning, by demultiplexing (reassembling) the incoming 

12 Ethernet frames into IP packets, and then demultiplexing the IP packets into the proper transport 

13 layer segments according to the proper protocols in order to extract the data from the packets. 

14 This would have been obvious because the ordinary person skilled in the art would have been 

1 5 motivated to use what was common and well known in the art. 

16 Regarding claims 2 and 17, Trcka and Stevens disclosed an incoming queue staging each 

17 incoming datagram intermediate to reassembly (See Trcka Col. 4 Line 8-10). 

18 Regarding claims 3 and 18, Trcka and Stevens disclosed a network protocol-specific 

19 decoder decoding the reassembled segment prior to scanning (See Stevens Page 1 1 and the 

20 rejection of claim 1 above). 

21 Regarding claims 5-6 and 20-21, Trcka and Stevens disclosed the antivirus scanner takes 

22 an action if the reassembled segment is infected with at least one of a computer virus and 



4 



It was well known that in the Internet Protocol there are multiple layers and that each 



9 



It would have been obvious to the ordinary person skilled in the art at the time of 
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1 malware, wherein the action comprises at least one of logging an infection; generating a 

2 warning; spoofing a valid datagram in place of the infected datagram; and acquiescing to the 

3 infection (See Trcka Col. 13 Lines 1-15). 

4 Regarding claims 7-10 and 22-25, Trcka and Stevens disclosed a protocol-specific queue 

5 staging each reassembled segment with other reassembled segments sharing the same transport 

6 protocol layer (See Trcka Gol. 17 Line 56 - Col. 18 Line 14, Col. 19 Lines 55-59 and Col. 20 

7 Lines 30-35), an information record storing information dependent on the same transport 

8 protocol layer with the staged reassembled segment (See Trcka Col. 12 Lines 7-1 1 and Col. 20 

9 Lines 34-35), a contents record storing the contents with the staged reassembled segment (See 

10 Trcka Col. 18 Lines 15-52), and wherein the information comprises at least one of a source 

1 1 address, source port number, destination address, destination port number, URL, file name, user 

12 name, sender identification, recipient identification, and subject (See Trcka Col. 18 Lines 3-14). 

13 Furthermore, in the demultiplexing taught by Stevens, it would be obvious for each "protocol 

14 box" which is receiving data and acting on the, to have a queue for storing the data before and 

15 during the processing of this protocol specific data. This would be obvious because the ordinary 

16 person skilled in the art would have been motivated to not lose the data if a "protocol box" is 

1 7 processing data slower than it is receiving the data. 

18 Regarding claims 13-14, and 28-29, Trcka and Stevens disclosed an event correlator 

19 analyzing the transient packet stream for events indicative of a network service attack (See Trcka 

20 Abstract and Col. 13 Lines 5-15), and a data repository maintaining each event (See Trcka Col. 7 

21 Lines 28-32). 
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1 Regarding claim 55, Trcka and Stevens disclosed that the incoming datagrams include IP 

2 datagrams that are reassembled into TCP segments (See Trcka Col. 14 Lines 61-67). 

3 Claims 4, 19, 32-38, 40-47, and 49-52, are rejected under 35 U.S.C. 103(a) as being 

4 unpatentable over Trcka and Stevens as applied to claim 1 above, and further in view of Cheriton 

5 (US Patent Number 7,054,930). 

6 Trcka and Stevens disclose detecting and responding to network attacks (See Trcka Col. 

7 1 1 Lines 14), but failed to specifically disclose detection or response to Denial of Service 

8 attacks, or terminating the transient packet stream if the reassembled segment is not infected with 

9 at least one of a computer virus and malware. 

10 Cheriton teaches that in a network, denial of service attacks can result in significant loss 

1 1 of time and money for many organizations (See Cheriton Col. 1 Lines 19-21), and further 

12 teaches detection of denial of service attacks (See Cheriton Col. 3 Lines 29-45) and teaches 

13 generation and refinement of filters for stopping the attack packets, and forwarding these filters 

14 upstream (See Cheriton Col. 2 Lines 16-24 and Col. 3 Lines 29-45, and Claim 7). 

.15 It would have been obvious to the ordinary person skilled in the art at the time of 

16 invention to employ the teachings of Cheriton in the network surveillance system of Trcka and 

17 Stevens by detecting Denial of Service attacks, and upon detection of such, creating a filter to 

1 8 prevent the flow of the Denial of Service packets, and forwarding the filter for use by an 

19 upstream device. This would have been obvious because the ordinary person skilled in the art at 

20 the time of invention would have been motivated to protect the network from Denial of Service 

21 attacks. 
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1 Regarding claims 32, 41, and 50, Trcka and Stevens disclosed a system for passively 

2 detecting computer viruses and malware and network attacks in a distributed computing 

3 environment (See Trcka Abstract), comprising: a network interface receiving copies of 

4 datagrams transiting a boundary of a network domain into an incoming packet queue (See Trcka 

5 Col 2 Lines 29-34, Col. 4 Lines 2-1 1, and Col. 7 Lines 28-32, and Col. 12 Lines 29-40), each 

6 datagram being copied from a packet stream (See Trcka Col. 14 Lines 34-36); a packet receiver 

7 reassembling one or more such datagrams from the incoming packet queue into network protocol 

8 packets, each staged in a reassembled packet queue (See Stevens Pages 6-11 and the rejection of 

9 claim 1 above); an antivirus scanner scanning each network protocol packet from the 

10 reassembled packet queue to ascertain an infection of at least one of a computer virus and 

1 1 malware (See Trcka Col. 3 Line 66 - Col. 4 Line 16) ; and an event correlator evaluating events 

12 identified from the datagrams in the packet stream to detect network attack on the network 

13 domain (See Trcka Abstract and Col. 13 Lines 5-15) ; wherein a protocol-specific module 

14 processes each reassembled datagram, based on an upper protocol layer employed by the 

15 reassembled datagram (See Stevens Page 1 1 and the rejection of claim 1 above), but Trcka and 

16 Stevens failed to specifically disclose detection of Denial of Service type network attacks. 

17 Cheriton teaches that in a network, denial of service attacks can result in significant loss 

18 of time and money for many organizations (See Cheriton Col. 1 Lines 19-21), and further 

19 teaches detection of denial of service attacks (See Cheriton Col. 3 Lines 29-45) and teaches 

20 generation and refinement of filters for stopping the attack packets, and forwarding these filters 

21 upstream (See Cheriton Col. 2 Lines 16-24 and Col. 3 Lines 29-45, and Claim 7). 
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1 It would have been obvious to the ordinary person skilled in the art at the time of 

2 invention to employ the teachings of Cheriton in the network surveillance system of Trcka and 

3 Stevens by detecting Denial of Service attacks, and upon detection of such, creating a filter to 

4 prevent the flow of the Denial of Service packets, and forwarding the filter for use by an 

5 upstream device. This would have been obvious because the ordinary person skilled in the art at 

6 the time of invention would have been motivated to protect the network from Denial of Service 

7 attacks. 

8 Regarding claims 33 and 42, Trcka, Stevens and Cheriton disclosed a parser parsing each 

9 reassembled datagram into network protocol-specific information and packet content (See 

10 Stevens Page 11). 

1 1 Regarding claims 34 and 43, Trcka, Stevens and Cheriton disclosed extracting the header 

12 information from the packets (See the rejection of claim 33 above), but failed to disclose 

13 specifically what information was contained in the headers. It was well known in the art at the 

14 time of invention that the headers of HTTP messages contained a source address and port 

15 number, a destination address and port number, and a URL, the headers of an FTP message 

16 contained the filename and username, and the headers for the SMTP contained the sender 

17 identifier, receiver identifier, and subject. As such, it would have been obvious to the ordinary 

1 8 person skilled in the art at the time of invention to employ what was well known by extracting 

19 the header information from the headers of the packets. This would have been obvious because 

20 the ordinary person would have been motivated to extract what was known to be contained in the 

21 header. 
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1 Regarding claims 35 and 44, Trcka, Stevens, and Cheriton disclosed a decoder decoding 

2 the packet content prior to performing the operation of scanning (See Stevens Page 1 1 and the 

3 rejection of claim 1 above). 

4 Regarding claims 36 and 45, Trcka, Stevens, and Cheriton disclosed a log logging an 

5 occurrence of at least one of the infection and the network attack (See Trcka Col. 17 Lines 38- 

6 40). 

7 Regarding claims 37, and 46, Trcka, Stevens, and Cheriton disclosed a warning module 

8 generating a warning responsive to an occurrence of at least one of the infection and the network 

9 attack (See Trcka Col. 13 Lines 1-15). 

10 Regarding claims 38 and 47, Trcka, Stevens, and Cheriton disclosed a spoof module 

1 1 sending a spoofed network protocol packet responsive to an occurrence of at least one of the 

12 infection and network attack (See Cheriton col. 10 Line 41- Col. 1 1 Line 8 and Trcka Col. 17 

13 Lines 37-39, wherein it would have been obvious to the ordinary person skilled in the art to send 

14 the detected spoofed packet to the log). 

15 Regarding claim 51, Trcka, Stevens, and Cheriton disclosed that the network protocol 

16 packets employ at least one of HTTP, FTP, SMTP, POP3, NNTP, and Gnutella network 

17 protocols (See Trcka Col. 18 Paragraphs 1-2). 

18 Regarding claim 52, Trcka, Stevens, and Cheriton disclosed that only datagrams 

19 compliant with IP protocol are reassembled (See Trcka Entire reference wherein only IP 

20 compliant protocols are disclosed). 
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1 Claims 15, and 30 are rejected under 35 U.S.C. 103(a) as being unpatentable over Trcka 

2 and Stevens as applied to claims 1 and 16 above, and further in view of Hailpern et al. (US 

3 " Patent Number 6,275,937) hereinafter referred to as Hailpern. 

4 Trcka and Stevens disclosed a system for scanning IP network packets for viruses (See 

5 the rejection of claim 1 above), but failed to disclose that all the incoming messages were SMTP 

6 compliant, and therefore TCP compliant. 

7 Hailpern teaches that virus scanning should be set up for each network protocol proxy, 

8 including E-mail, in order to scan for viruses (See Hailpern Col. 4 Lines 1-13). 

9 It would have been obvious to the ordinary person skilled in the art to employ the 

10 teachings of Hailpern in the virus scanning system of Trcka and Stevens by modifying mail 

1 1 servers to contain the scanning system of Trcka and Stevens. This would have been obvious 

12 because the ordinary person skilled in the art would have been motivated to enable the proxies to 

13 be able to scan the types of communications they already process and therefore reduce network 



14 traffic and delay. Further, SMTP mail servers were well known in the art at the time of 

15 invention, and it would have been obvious to utilize the scanning system of Trcka and Stevens in 

16 an SMTP mail server. This would have been obvious because the ordinary person skilled in the 

1 7 art would have been motivated to protect SMTP mail servers from viruses. 

18 Claims 40, 49, and 52 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

19 Trcka and Stevens and Cheriton as applied to claims 32 and 41 above, and further in view of 

20 Hailpern et al. (US Patent Number 6,275,937) hereinafter referred to as Hailpern. 
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1 Trcka, Stevens, and Cheriton disclosed a system for scanning IP network packets for 

2 viruses (See the rejection of claim 1 above), but failed to disclose that all the incoming messages 

3 were SMTP compliant, and therefore TCP/IP compliant. 

4 Hailpern teaches that virus scanning should be set up for each network protocol proxy, 

5 including E-mail, in order to scan for viruses (See Hailpern Col. 4 Lines 1-13). 

6 It would have been obvious to the ordinary person skilled in the art to employ the 

7 teachings of Hailpern in the virus scanning system of Trcka, Stevens, and Cheriton by modifying 

8 mail servers to contain the scanning system of Trcka, Stevens, and Cheriton. This would have 

9 been obvious because the ordinary person skilled in the art would have been motivated to enable 

10 the proxies to be able to scan the types of communications they already process and therefore 

1 1 reduce network traffic and delay. Further, SMTP mail servers were well known in the art at the 

12 time of invention, and it would have been obvious to utilize the scanning system of Trcka and 

13 Stevens, and Cheriton in an SMTP mail server. This would have been obvious because the 

14 ordinary person skilled in the art would have been motivated to protect SMTP mail servers from 

15 viruses. 

16 Claims 53-54, and 57 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

17 Trcka, Stevens, and Cheriton as applied to claim 32 above, and further in view of Epstein et al. 

1 8 (US Patent Number 6,684,329) hereinafter referred to as Epstein.. 

19 Trcka, Stevens, and Cheriton disclosed scanning packets for viruses (See Trcka Col. 1 1 

20 Lines 1-4), but failed to disclose sub-modules which each scan one of HTTP, FTP, SMTP, and 

21 NNTP packets. 
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1 Epstein teaches that in a firewall which scans for viruses, proxy sub-modules should be 

2 provided in the firewall for each of HTTP, FTP, SMTP, and NNTP protocol packets (See Epstein 

3 Col. 1 Lines 27-53 and Col. 3 Lines 8-21). 

4 It would have been obvious to the ordinary person skilled in the art at the time of 

5 invention to employ the teachings of Epstein in the virus scanning of Trcka, Stevens, and 

6 Cheriton by providing protocol specific proxy servers in the surveillance module to scan each of 

7 HTTP, SMTP, FTP, and NNTP packets. This would have been obvious because the ordinary 

8 person skilled in the art would have been motivated to provide the network administrator with 

9 greater control over the traffic which traversed the network. 

10 Regarding claim 57, although Trcka, Stevens, and Cheriton did not specifically teach that 

1 1 each of the protocol specific scanning sub-modules is used for retrieving a re-assembled packet 

12 from an associated protocol-specific queue, this is obvious in view of the fact that in TCP/IP, as 

13 evidenced by Stevens on pages 10-11, between the transport layer and the application layer, the 

14 application data from each datagram must be stored in order for it to be processed by the 

1 5 appropriate application, to get the user data which is to be scanned. As such, it would have been 

16 obvious to the ordinary person skilled in the art to have stored the application data generated 

17 through the demultiplexing at the transport layer. This would have been obvious because the 

1 8 ordinary person skilled in the art would have been motivated to not "lose" the data between the 

19 transport layer and the application layer. Furthermore, Stevens shows on Page 1 1 that each 

20 application receives its associated packets, thereby meeting the claim limitation. 
21 

22 
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1 



Conclusion 



2 



Claims 1-10, 13-25, 28-38, 40-47, and 49-57 have been rejected. 



3 



THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 



4 



policy as set forth in 37 CFR 1.136(a). 



5 



A shortened statutory period for reply to this final action is set to expire THREE 



6 MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 

7 MONTHS of the mailing date of this final action and the advisory action is not mailed until after 

8 the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 

9 will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 

10 CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 

1 1 however, will the statutory period for reply expire later than SIX MONTHS from the mailing 

1 2 date of this final action. 

13 Any inquiry concerning this communication or earlier communications from the 

14 examiner should be directed to MATTHEW T. HENNING whose telephone number is 

1 5 (571)272-3790. The examiner can normally be reached on M-F 8-4. 

16 If attempts to reach the examiner by telephone are unsuccessful, the examiner/ s 

17 supervisor, Ayaz Sheikh can be reached on (571) 272-3795. The fax phone number for the 

18 organization where this application or proceeding is assigned is 571-273-8300. 
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1 Information regarding the status of an application may be obtained from the Patent 

2 Application Information Retrieval (PAIR) system. Status information for published applications 

3 may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 

4 applications is available through Private PAIR only. For more information about the PAIR 

5 system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 

6 system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
7 

8 /Matthew T Henning/ 

9 Examiner, Art Unit 2131 
10 2/8/2008 




